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1  Introduction 


Database  management  systems  have  become  widely  recognized  as  a  means 
of  sharing  and  maintaining  data  in  a  way  that  avoids  redundancy  and  incon¬ 
sistency.  They  allow  the  user  to  insert,  delete  and  modify  data  and  perform 
simple  queries  with  a  minimum  of  effort. 

In  recent  years,  however,  the  use  of  database  systems  has  been  extended 
to  more  and  more  complex  applications.  Databases  address  not  just  the  pre¬ 
dictable  information  required  by  a  personnel  department  of  a  company,  but 
also  the  less  predictable  information  required  by  an  object  oriented  simula¬ 
tion,  an  expert  system,  or  a  battlefield  commander.  Techniques  developed 
with  business  applications  in  mind  do  not  always  provide  the  query  flexibility 
required.  Further,  they  do  not  extend  themselves  easily  to  take  advantage 
of  rapidly  developing  technologies  like  parallel  computation  and  automatic 
program  transformation. 

Logical  databases  are  very  attractive  for  maintaining  and  manipulat¬ 
ing  knowledge  and  are  predicted  by  some  to  be  the  data  management  sys¬ 
tem  of  the  future[l].  Reasons  for  this  prediction  are  that  the  approach  is: 
well  founded,  as  it  is  based  on  logic;  cohesive,  as  it  allows  data  structures, 
queries  and  computations  in  a  single  notation;  declarative  and  therefore 
non  sequential,  providing  more  potential  for  tapping  the  faster  computing 
speeds  of  parallel  processors.  These  features  can  greatly  improve  program 
maintenance,  reliability,  generality  and  efficiency. 

In  this  project  we  select  an  existing  distributed  fact  base  and  reformulate 
it  as  a  logical  database.  Next,  we  construct  some  sample  queries.  Finally, 
we  address  possible  query  transformations  and  their  impact  on  the  efficiency 
of  the  associated  queries.  This  approach  allows  evaluation  of  the  logical 
database  approach:  the  relative  ease  of  development,  query  flexibility  and 
efficiency.  These  issues  are  addressed  in  this  paper.  Further,  the  dynamic 
nature  of  the  knowledge  base  selected  allows  us  to  examine  compromises 
between  absolute  logical  correctness  and  conclusions  based  on  imperfect, 
incomplete,  or  changing  data.  Future  work  will  examine  this  problem,  as 
well  as  data  visualization  and  query  scheduling. 


2  The  Information  Distribution  System 

Battlefield  management  has  been  identifier  as  a  major  thrust  for  future 
Army  technological  development^].  Here  we  find  a  prime  example  of  the 
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IDS 


Figure  1:  The  Information  Distribution  System.  (For  this  project,  browsing 
operations  are  being  developed  to  query  the  FACTBASE.) 


need  for  both  query  flexibility  and  efficiency.  In  a  highly  dynamic,  unpre¬ 
dictable  and  hostile  combat  environment,  it  is  crucial  that  queries  be  easily 
formulated  and  quickly  resolved. 

The  Information  Distribution  System  (IDS)  was  developed  as  an  ex¬ 
perimental  prototype  to  evaluate  various  data  abstraction  and  distribution 
technologies  for  automatically  distributing  information  to  and  among  fight¬ 
ing  level  forces.  It  assumes  low  bandwidth  communications  in  +he  tactical 
combat  environment.  Specifically,  it  addresses  how  to  insure  required  bat¬ 
tlefield  information  is  available  at  the  various  locations  where  the  battlefield 
management  function  is  performed.  As  part  of  this  prototype,  a  FACT- 
BASE  was  developed,  which  accommodates  the  wide  variety  of  information 
required  at  brigade  and  below.  Various  application  programs  then  access  the 
FACTP/,CE  information  through  the  IDS  interface  [3].  Figure  1  illustrates 
the  ILS  structure  and  its  relationship  to  the  various  IDS  applications. 
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The  FACTBASE  consists  of  various  C  programming  structures  and  has 
a  small  query  language  with  a  C-like  syntax.  Some  facts  are  relatively 
static  over  time,  while  others  are  more  dynamic  [4].  The  information  in  the 
FACTBASE  is  complex,  requiring  all  three  possible  database  schemes:  hier¬ 
archical,  for  the  organizational  structure;  network,  for  the  communications 
connectivity;  and  relational,  for  the  logistics  data  found  in  TO&E  or  equip¬ 
ment  manuals.  This  FACTBASE  serves  as  the  foundation  for  our  logical 
database. 


3  Logical  Databases 

Logic  is  a  branch  of  mathematics  which  allows  the  explicit  expression  of 
goals,  knowledge,  and  assumptions.  It  supplies  a  foundation  for  deduc¬ 
ing  conclusions  from  premises  and  for  determining  validity  and  consistency. 
Logic  programming  is  a  formal  system  for  specifying  objects  and  relations 
between  objects.  It  departs  radically  from  the  mainstream  of  computer  lan¬ 
guages.  It  is  not  derived  from  a  physical  machine’s  instruction  set,  but  is 
instead  founded  on  an  abstract  model  based  on  first  order  logic[5].  A  logical, 
or  deductive,  database  is  a  set  of  facts  that  are  c  mbined  with  a  set  of  rules 
to  allow  new  facts  to  be  inferred  and  new  reP  mnships  to  be  defined.  A 
logical  database  is  firmly  and  declaratively  founded  on  a  small,  but  pow¬ 
erful,  set  of  primitives.  This  characteristic  increases  reliability,  confidence, 
and  efficiency. 

Some  of  the  dominant  areas  of  interest  in  logic  programming  are  pro¬ 
gram  correctness,  program  optimization,  parallelism  and  program  synthe¬ 
sis.  Major  applications  of  logic  programming  have  been  made  to  intelligent 
databases,  natural  language  processing,  computer  aided  design,  molecular 
biology,  and  high  level  compilation. 

Logic  programming  attempts  to  apply  the  rigor  of  formal  logic  to  com¬ 
plex,  computer-based  systems  that  lack  such  logical  foundations.  It  is  an 
ideal  that  has  not  been,  and  may  never  be,  realized  on  an  existing  machine. 
One  approximation  is  given  by  the  programming  language,  Prolog.  Prolog 
compilers  have  become  very  efficient  primarily  as  a  result  of  work  by  Warren 
and  his  colleagues[6].  This  application  is  being  developed  in  Prolog. 


4  Developing  a  Logical  FACTBASE 

We  began  this  project  by  constructing  a  parser  and  translator  to  transform 
the  IDS  FACTBASE  into  equivalent  logical  relations,  which  we  refer  to 
as  the  Logical  FACTBASE.  The  result  of  the  translation  is  a  collection 
of  approximately  30,000  Prolog  clauses.  This  representation  can  include 
networks,  hierarchies  and  relations.  For  the  initial  phase  of  the  project,  we 
have  confined  ourselves  to  the  static  portions  of  the  database,  intending  to 
address  the  dynamic  portions  in  the  future.  The  static  portions  include  the 
general  unit  or  system  properties  while  the  dynamic  portions  include  such 
changing  values  as  unit  location  or  assignment. 

The  founding  data  structure  for  the  database  is  the  term,  made  up  of 
variables  and  constants.  Variables  are  represented  by  character  strings  be¬ 
ginning  with  an  upper  case  character.  Special  characters  and  strings  be¬ 
ginning  with  lower  case  characters  are  constants.  As  Figure  2  illustrates,  a 
term  may  be  thought  of  as  a  tree-like  structure  with  leaves  that  are  variables 
or  constants  (like  3,  pi,  Y  or  2  in  Figure  2).  The  root  and  internal  nodes 
of  the  graph  are  constants  and  are  called  function  symbols  (  +  ,*,sin  and 
/).  The  root  (  +  )  is  the  principal  function  symbol.  It  is  important  to  note 
that  function  symbols  are  passive,  syntactic  objects  without  any  implied 
interpretation. 

More  precisely,  a  term  is  either  a  variable,  a  constant,  or  a  function 
symbol  with  arguments  that  are  terms.  The  most  general  term  is  simply 
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a  variable.  A  term  whose  leaves  are  all  constants  is  called  a  ground  term. 
In  the  usual  Prolog  system,  constants  are  stored  only  once  and  all  other 
occurrences  are  simply  pointers  to  the  centrally-stored  constant.  Similarly, 
if  a  variable  occurs  twice  in  a  term,  both  occurrences  refer  to  the  same 
variable  (like  Y  in  Figure  2).  Thus,  a  term  is  not  really  a  tree  but  a  directed, 
acyclic  graph,  that  is,  a  tree  with  shared  branches.  This  sharing  can  mean 
significant  savings  in  storage  and  is  a  side  effect  of  the  unification  algorithm, 
discussed  in  the  next  section. 

One  special  kind  of  term  is  the  list.  A  list  is  made  up  of  a  nested 
sequence  of  pairs  indicated  with  the  period  as  principal  function  symbol. 
For  example,  a  list  of  the  first  five  integers  is  .(1,  .(2,  .(3,  .(4,  .(5,  [  ]))))), 
where  we  are  representing  the  empty  list  with  [  ].  More  convenir  'y,  we  can 
represent  this  list  as  (1,2,3, 4,5]. 

Intuitively,  a  term  may  make  up  an  entire  fact  or  it  may  be  the  argument 
in  a  rule  stating  a  fact.  Terms  also  play  the  role  of  arrays,  pointers,  and 
record  data  structures. 

A  rule  is  the  fundamental  statement  in  a  logic  program  or  logical  database. 
A  rule  has  a  head  and  body  separated  by  *:  — it  ends  with  a  period.  The 
head  contains  at  most  one  term,  and  the  body  contains  zero  or  more  terms 
separated  by  a  comma.  We  can  read  a  rule  declaratively,  that  is  as  a  state¬ 
ment  of  fact.  For  example, 


P  :  -  Q,R. 

means  that  P  is  true  if  Q  is  true  and  R  is  true.  A  rule  is  also  called  a  clause. 
A  unit  clause  is  a  clause  in  which  the  body  is  empty.  A  logic  program  is  a 
set  of  clauses. 

The  IDS  data  was  translated  into  unit  clauses  whose  principal  function 
symbols  have  two  arguments.  These  define  proper  binary  relations  and  are 
to  be  read  as  statements  of  fact.  An  example  would  be  the  clause 

ech{'U\  000000'/  CO  R') . 

This  is  a  unit  clause  whose  head  is  a  single  term.  The  principle  function  sym¬ 
bol  is  ech  and  it  has  two  arguments,  ’U 1000000’  and  ’COR’.  The  function 
symbol  can  also  be  placed  between  its  arguments,  in  infix  form,  as 

'U 1000000'  ech  'COR'. 

Binary  representation  was  chosen  for  several  reasons.  First,  it  is  simple; 
database  entries  are  easily  written,  easily  searched,  and  can  often  be  read 


5 


FACTBASE  ENTRY 


°r*_lype 

i 

ldnum  =  ’U1000000*; 
name  =  ’US  CORPS  (HEAVY)*; 
ech  =  ’COR’ ; 
sym  =  ’F1CORHV’, 

sub  =  [  7  org_type  {S.idnum  ==  ’U1000100'},  1, 

7  org_type  {S.idnum  ==  "U1 100000") .  2. 

7  org_type  {S.idnum  ==  "U1 200000") ,  2. 
?  org_type  (S.idnum  s=  "Ul 300000"} .  1, 

?  org_type  {S.idnum  ==  "U1040000"}.  1, 
?  org_iype  {S.idnum  ==  "U10600Q0").  lj; 


LOGICAL  FACTBASE 
EQUIVALENT 

’U1000000’  category  org. 

•U1000000’  unit  name  ’US  CORPS  (HEAVY)'. 
’U1000000’  ech **COR’ . 

*1/1000000'  sym  FlCOkHV\ 

‘U1000000’  sub_umt[idnum(’U1000100‘),  num(l)] 
'U1000000*  sub_unil[idnum(’Ul  100000’),  num(2)j 
‘U1000000’  sub_unii[idnum(’U1200000’),  num(2)j 
’U1000000*  sub_uniifidnum('U1300000'),  num(l)j 
‘U1000000’  5ub_unii(idnum(’U1040000’),  num(l)j 
’U1000000'  sub_unit[idnum(’U1060000'),  num(l)j 


equip 

{ 

model  = 
class  * 
type  * 
desc  * 
props  = 
attr  = 


dummy} . 


’AN/TPO-36*; 

’veh’; 

’elec*; 

’Mortar  Locating  Radar  Set*; 

’E’i 

[  7  equipwattr  (maxrg  ==  15000  AA  alt  == 
’mort/any*} , 

[  7  equtp_attr  (maxrg  ==  24000  AA  alt  == 
’rockets’}  ]; 


type  (elec),  model  (’AN/TPO-36’) 
type  (elec),  model  (’AN/TPO-36*) 
type  (elec),  model(*  AN/TPO-36’) 


category  equip, 
class  veh. 
desc  'Mortar 


Locating  Radar  Set’ 


(type  (elec),  model(’  AN/TPO-36  ‘)]maxrg{  15000, 

’mort/arty’]. 

[type  (elec).  modelC  AN /TPO-36*)]maxrg(24000. 

rockets]. 


Figure  3:  An  example  of  an  IDS  fact  and  its  translation  to  proper  relation 
form. 


as  if  they  were  sentences.  Second,  with  this  approach,  there  is  no  loss  of 
computational  power.  Rules  on  binary  relations  can  compute  anything  that 
rules  on  n-ary  relations  can  compute[7].  Finally,  the  method  we  use  later 
for  transforming  queries  requires  that  the  relations  have  two  arguments[8]. 

Figure  3  illustrates  the  translation  of  two  FACTBASE  entries  from 
their  original  C  structure  into  their  logical  representation.  The  C  structures 
typically  consist  of  a  fact  type,  followed  by  a  series  of  subfield  identifiers 
which  are  associated  by  =  with  a  subfield  value.  In  the  example,  org.type 
and  equip  are  both  fact  types.  Looking  more  closely  at  orgJype ,  idnum  is 
a  subfield  identifier,  and  its  value  is  U1000000,  a  unique  unit  identification 
code  developed  for  IDS  applications.  A  unit  clause  is  asserted  for  each  of 
these  triples,  with  the  subfield  identifier  becoming  the  binary  relation.  The 
fact  type  and  subfield  value  are  the  relation’s  arguments.  A  subfield  value 
of  ' E'  indicates  an  empty  field  and  is  not  translated.  In  the  example,  one 
organizational  fact  is  translated  to  10  unit  clauses.  Their  principal  function 
symbols  are  category,  unit-name,  ech,  sym  and  sub.unit.  Each  relation  has 
2  arguments.  The  sub.unit  function,  for  example,  has  2  arguments:  parent 
unit  id;  and  a  list  of  2  terms,  the  subunit  and  its  number  of  occurrences. 

After  the  translation  was  accomplished,  a  small  parser  was  written  in 
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i  i olog,,  iii  which  the  operator  precedence,  position,  class  and  associati' 


“-j 


were  established.  The  binary  relations  resulting  from  the  translation  were 
all  defined  in  infix  form. 

Finally,  the  database  was  extended  with  new  relations.  These  relations 
were  not  part  of  the  organizational  or  logistical  structure,  but  were  created  to 
help  form  new  queries.  For  example,  as  illustrated  in  Figure  3,  we  know  the 
maximum  range  of  our  weapons.  We  can  extend  the  data  by  defining  what 
we  mean  for  a  given  distance,  R,  to  be  within  firing  range  of  a  particular 
weapon  of  type  T  and  model  M: 


[T,  M]  can./ireuit Jargets-at. range  R  :  - 
[T,M]  maxrg  [Range, -Alt], 

Range  >  R. 


This  new  relation  could  be  useful  in  searching  for  the  right  weapon  to 
use  against  a  given  target.  The  new  relations  extend  the  translated  database 
entries  to  a  conceptually  larger  database.  They  are,  in  fact,  rules  that  assist 
in  formulating  queries.  This  brings  us  to  our  next  topic. 


5  Querying  the  Logical  FACTBASE 

The  next  step  in  the  application  was  to  construct  some  queries.  The  fun¬ 
damental  tools  for  querying  are  unification  and  backward  inferencing.  We 
therefore  begin  this  section  with  a  brief  explanation  of  these  basic  proce¬ 
dures. 

The  unification  algorithm  is  a  solution  procedure  that  derives  values  for 
variables  from  an  equation  between  two  terms.  Given  two  terms  5  and  T 
the  unification  algorithm  determines  values  for  variables  as  follows: 

•  if  5  and  T  are  both  constants  then  unification  succeeds  if  they  are 
identical  and  fails  if  they  are  different. 

•  if  5  is  a  variable,  then  the  value  for  5  is  5  =  T.  (Symmetrically,  if  T 
is  a  variable,  then  the  value  for  T  is  T  =  S.) 

•  if  5  and  T  are  more  general  terms  with  the  same  function  symbols, 
then  the  solution  is  determined  by  corresponding  unification  of  their 
arguments. 

•  if  S  and  T  are  more  general  terms  with  different  function  symbols  then 
unification  fails. 
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DATABASE  REPRESENTATION 

— 

PARENT  RELATION  GRAPH 

FACTS 

Dionysus 

zeus  is_father_of  donysus. 
semele  is_mother_of  dionysus. 

Semele 

cadmus  is_!ather_of  semele 
harmoma  is_mo thereof  semele. 

^ Cadmui 

ares  is_father__of  harmoma. 
aphrodite  t$_mother_of  harmoma. 

f  Ares  Aphrodite 

zeus  is_father-of  ares 
hera  is”mother_o(  ares 

- - ^ 

Zeus  Hera 

RULES 

X  is_parent_of  Y  :  -  X  is_fathcr_of  Y 

X  is_parent~of  Y  :  -  X  is”mothe7_of  Y. 

Figure  4:  Representing  the  parent  relationship  in  a  logical  database. 


Unification,  then,  can  be  applied  to  extract  components  of  clauses.  Figure 
4  illustrates  a  familiar  example  of  a  family  database  [9].  In  this  example, 
consider  unifying  the  two  terms  A'  is.father.of  ares  and  zeus  is.father.of  V. 
From 


A'  is.f  'at  her. of  ares  =  zeus  is.father.of  Y 

we  would  conclude  that  a  value  for  X  is  A'  =  zeus  and  a  value  for  Y  is 

Y  -  ares. 

The  second  fundamental  tool  is  backward  inferencing,  which  is  essen¬ 
tially  the  application  of  one  rule  to  a  goal,  reducing  it  to  a  conjunction 
of  subgoals.  Inferencing  allows  us  to  arrive  at  conclusions  from  facts  and 
rules.  For  example,  in  Figure  4,  zeus  is.parent.of  Y  can  be  reduced  to  zeus 
is.f  other. of  Y  using  the  very  first  rule  allowing  us  to  eventually  infer  that 

Y  =  dyonysus.  If  we  look  for  more  solutions,  we  find  that  Y  =  ares  also 
satisfies  the  query. 

A  goal ,  or  in  our  case  a  database  query,  is  a  clause  with  an  empty  head. 
This  goal  is  a  conjunction  of  subgoals  which  is  solved  by  solving  all  sub¬ 
goals.  Each  subgoa!  is  solved  by  unifying  it  with  the  head  of  a  clause  in 
the  database.  This  creates  values  for  variables.  A  single  backward  inference 
reduces  this  subgoal  to  another  conjunction  of  subgoals  until  reaching  the 
subgoa!  true ,  which  is  trivially  solvable.  In  Prolog,  subgoals  are  solved  in 
sequential,  left  to  right  order  and  clauses  are  chosen  in  top  to  bottom  order 
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DATABASE  REPRESENTATION 


■B3220000'  »ub__umt  {idnumCB32201Q0'),  num(l)J. 
’B3220000‘  *ub_unit  [idnum(,B3223000') .  num(l)]- 
’B3220000'  «ub_umi  ftdnum(’B3224000'),  num(l)]- 


'B3223000'  *ub_unit  (idnum(*B3223200*),  num(l)]- 
' B3223000 '  *ub_unit  (idnum(,B3223600'),  num(l)]. 


B3223200’  »ub_un»t  (idnum('B32232lO’)>  num(!)]. 
’ B3223600 ’  lub.umt  [idnum(’B32236lO,>.  num(l)J. 
’B3223600'  *ub_umi  (idnum(*B3223620’) ,  num(l)]. 


ORGANIZATION  HIERARCHY 


B3220100  B3223000  B3224000 


B3223200  B3223600 


B3223210  B3223610  B3223620 


Figure  5:  Representing  the  subunit  relationship  in  the  Logical  FACTBASE. 


with  backtracking  to  find  additional  solutions.  Again,  looking  at  Figure  4, 
we  can  determine  who  are  the  parents  of  Semele  by  solving  the  goal 

:  —A"  is.parentjof  semele. 

This  unifies  with  the  head  of  the  first  rule,  yielding  X  is.father^)/  semele. 
The  solution  for  X  in  that  subgoal  is  X  =  cadmus.  Alternatively,  the  goal 
resolves  to  A'  is. mother  jo  f  semele ,  in  which  we  find  a  alternate  solution 
A'  =  harmonia. 

In  Figure  5  we  extend  this  technique  to  the  FACTBASE  data,  using 
the  subunit  relation  somewhat  like  the  parent  relation.  A  subunit  B  means 
thatA  and  B  are  members  of  the  subunit  relation,  with  A  being  the  parent 
unit. 

Once  the  database  has  been  established,  a  number  of  queries  can  be 
solved  without  any  programming,  by  the  selective  placement  of  constants 
and  variables  in  goals.  Prolog  attempts  to  unify  the  goal  with  unit  clauses 
in  the  database.  For  example,  using  the  data  in  Figure  5,  we  may  identify 
all  the  subunits  of  B3220000,  with  the  simple  query,  ’BS220000'  sub.unit 
X.  Further,  all  relations  defined  with  unit  clauses  can  be  queried  in  either 
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direction.  This  is  a  powerful  aspect  of  the  unification  aigorithm,  for  it  allows 
us  to  answer  questions  about  the  converse  of  a  relation  in  the  database  as 
well  as  about  the  relation  itself.  For  example,  the  subunit  relation  has  been 
defined,  so  we  have  immediate  access  to  its  converse,  the  parent  relation. 
That  is,  we  can  identify  the  parent  unit  for  B3223600  through  the  query, 
X  sub.unit  [idnum(,B3223600’)l  .num].  Similar  queries  can  be  made  for  all 
relations  established  in  the  database.  Queries  solved  with  a  single  unification 
are  satisfied  almost  immediately. 

As  indicated  previously,  more  complex  queries  may  require  the  definition 
of  new  relations.  Suppose  we  wish  to  know  whether  B3223610  is  under  the 
control  of  B3223000.  In  this  case,  we  would  like  to  know  if  B3223610  is  a 
subunit  of  B3223000,  or  if  it  is  a  subunit  of  a  subunit  of  B3223000,  etc.  We 
define  the  controls  relation  recursively  as  follows: 

A  controls  B  :  —  A  subunit  B. 

A  controls  B  :  —  A  subunit  C , 

C  controls  B. 

Now,  we  may  query  with  the  goal  ’B3223000’  controls  B3223610’.  Prolog 
verifies  that  there  is  a  path  through  the  organization  graph  in  Figure  5  from 
B3223000  to  B3223610  through  B3223600,  returning  the  answer  true. 

6  Query  Transformations 

Finally,  we  address  possible  query  transformations  and  their  resulting  im¬ 
pact  on  the  efficiency  of  the  associated  queries.  Sometimes  the  most  obvious 
expression  of  a  query  is  not  the  most  efficient  for  implementation,  as  illus¬ 
trated  in  the  example  below.  One  of  the  benefits  we  hope  to  derive  from  this 
logical  approach  to  computation  is  to  be  able  to  state  queries  in  a  straight¬ 
forward  manner,  and  then  reliably  transform  these  queries  to  optimize  their 
execution. 

The  solution  procedure  for  a  query  starts  by  unifying  the  goal  with  the 
head  of  a  clause  to  determine  values  for  variables.  This  environment  is  used 
to  solve  each  subgoal  of  the  body  in  turn.  If  any  subgoal  is  unsolvable  then 
alternate  clauses  are  applied  by  backtracking  to  create  possible  alternate 
paths.  A  solution  can  be  found  more  efficiently  if  the  search  can  be  correctly 
constrained  in  the  appropriate  direction.  But  note  that  an  overconstrained 
system  may  be  unsolvable. 

Consider  the  problem  of  searching  for  a  path  through  a  graph  described 
by  a  relation  R.  This  is  essentially  asking  if  the  two  endpoints  (x,y)  of  the 
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graph  are  members  of  the  transitive  closure  R+  of  R.  A  pair  is  a  member  of 
the  transitive  closure  of  R  if  either  the  pair  is  in  R  or  there  is  an  intermediate 
point  z  such  that  (x,  z)  is  in  R  and  ( z ,  y)  is  in  R+ .  In  symbols  this  is  written 
as 

R+  =  {(x,y)| (x,y)  e  R  or  3 z,(x,z)  €  R,  and  ( z,y )  e  5+}. 

Operationally,  R+  is  the  exhaustively  repeated  application  of  R. 

The  controls  relation,  that  is  the  transitive  closure  of  the  subunit  rela¬ 
tion,  provides  a  perfect  example  of  how  we  can  improve  the  efficiency  of  the 
solution  procedure  by  transforming  the  query.  In  this  example,  we  say  that 
A  controls  B  if  there  is  a  path  from  A  to  B  in  the  graph  formed  by  the 
subunit  relation.  The  controls  definition  naturally  schedules  subgoals  from 
the  top  of  the  command  hierarchy  downward.  As  illustrated  in  the  following 
example,  this  schedule  is  inappropriate  and  inefficient  for  the  database  as 
structured.  A  bottom  up  search  would  have  been  better. 

Consider  the  command  hierarchy  depicted  in  Figure  6.  In  this  graph, 
the  lines  indicate  the  subunit  relation,  with  higher  nodes  indicating  parent 
units  and  lower  nodes  their  subunits.  This  simplified  example  allows  us  to 
limit  the  controls  relation  to  two  levels.  That  is,  a  unit  controls  its  subunits 
and  its  subunits’  subunits.  To  determine  if  53224600  is  under  the  control 
of  53220000  we  find  an  intermediate  unit  V  such  that  53220000  subunit  V 
and  V  subunit  53224600.  Efficiency  greatly  depends  on  which  subgoal  is 
selected  first.  If  we  start  with  the  goal  53220000  subunit  V  then  we  have 
multiple  solutions,  requiring  us  to  travel  through  the  tree,  first  through  node 
B3220100  and  its  subunits,  then  through  node  B3223000  and  its  subunits, 
and  finally  to  our  solution  point  under  B3224000.  On  the  other  hand,  if  we 
start  with  the  goal  V  subunit  5 3224600,  it  has  a  unique  solution,  quickly 
generating  our  solution  path. 

The  reason  that  the  second  subgoal  should  be  chosen  first  is  that  the 
converse  of  the  subunit  relation,  denoted  (subunit"'),  is  a  function.  Each 
unit  has  exactly  one  parent  unit.  Thus  it  would  be  much  more  efficient  to 
carry  out  the  search  in  this  order,  as  each  choice  would  be  unique.  We, 
therefore,  transform  the  query  to  find  a  path  in  the  tree  with 

controls~  =  (subunit"' )+ , 

denoting  transitive  closure  with  +.  The  subunit  relation  does  indeed  de¬ 
fine  a  tree,  so  A  controls  B  is  reversible.  Since  the  converse  of  subunit 
is  a  function,  the  paths  through  the  tree  can  be  most  efficiently  found  by 
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ORGANIZATION  HIERARCHY 


B3220000 


B3223200  B3223600  B3224200  B32246Q0 


Figure  6:  A  sample  command  hierarchy  graph. 


searching  up  the  tree  instead  of  top  down.  The  bottom  up  search  requires 
no  backtracking.  Here  we  note  that  it  is  the  nature  of  the  subunit  relation 
that  suggests  this  transformation.  For  the  large  organizational  structure  in 
the  IDS,  the  bottom  up  solution  of  a  sample  query  was  immediately  solved 
whereas  the  corresponding  top  down  query  took  more  than  an  hour. 

The  reversibility  of  the  unification  algorithm  is  what  allows  us  to  repre¬ 
sent  converse  relations.  Some  knowledge  about  reversibility  can  save  a  great 
deal  of  computation  time.  Searches  both  up  and  down  the  hierarchy  in  the 
originally  defined  IDS  database  would  have  required  that  we  add  the  con¬ 
verse  relations  to  the  data,  essentially  doubling  the  storage  requirements  for 
the  subunit  relation.  This  trades  storage  for  time,  and  sacrifices  modularity 
and  maintainability.  With  our  new  approach,  the  tradeoff  is  unnecessary. 

On  the  other  hand,  while  queries  are  completely  reversible  when  solved 
with  unit  clauses,  termination  is  unpredictable  in  general.  In  Prolog,  some 
queries  that  can  be  easily  solved  in  the  forward  direction  may  not  termi¬ 
nate  in  the  reverse  direction.  In  addition,  some  operations  in  Prolog  only 
have  meaning  when  all  arguments  are  ground  terms.  Attractive  solutions  to 
these  problems  are  emerging  from  research  in  constraint  logic  programming 
and  higher  order  extensions  to  logic  programming[8,10].  These  approaches 
solve  bigger  classes  of  problems  by  giving  declarative  extensions  to  some 
operations  in  logic  programming  such  as  negation,  inequality,  and  ordering. 
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7  Future  Work 


Future  work  will  emphasize  three  main  areas:  first,  the  notoriously  difficult 
problem  of  synchronizing  data  updates  with  data  queries,  including  deter¬ 
mining  constraints  that  can  maintain  integrity;  second,  methods  of  pictori- 
ally  representing  the  relations  in  the  Logical  FACTBASE  and  the  associated 
queries;  and,  finally,  further  query  optimizations. 

In  Section  2  we  indicated  that  the  static  portions  of  the  FACTBASE 
were  translated  first.  The  dynamic  data  would  be  translated  in  future.  This 
is  because  logic  programming  with  a  set  of  clauses  does  not  accommodate 
axioms  that  may  be  modified  in  the  middle  of  a  deduction  [11].  An  at¬ 
tractive  compromise,  however,  can  be  derived  from  a  thorough  treatment  of 
binary  relations[8,12].  Accepting  the  fact  that  change  is  an  integral  part  of 
our  distributed  database,  we  concentrate  on  cleanly  separating  the  abstract 
portions  of  our  relations,  the  rules,  from  the  facts.  That  is,  we  separate  the 
program  from  the  data.  Once  this  is  accomplished,  the  algebra  of  equations 
between  relations  is  an  appropriate  formalism  and  an  ideal  foundation  for 
query  optimizations  that  hold  independently  of  the  data.  The  FACTBASE 
information  will  be  set  aside  as  an  area  designated  to  be  modified.  Queries 
operate  on  a  snapshot  of  the  database  without  attempting  to  maintain  a 
notion  of  logical  truth.  Equations  between  combinations  of  relations  hold 
independently  of  the  data.  We  extend  this  concept  and  further  partition  the 
data  into  distinct  relations  to  represent  partitions  of  the  database  such  as 
subunit  and  owns. equipment.  Then  we  can  pass  these  relations  along  as  ar¬ 
guments  to  the  previous  operations.  This  adds  another  level  of  generality  to 
the  query  language  so  that  generic  operations  can  be  defined  and  applied  to 
portions  of  the  database  or  to  other  predefined  operations  on  the  database. 

Secondly,  we  will  experiment  with  ways  of  pictorially  representing  the 
relations  in  the  logical  FACTBASE  and  the  associated  queries.  There  is  a 
close  relationship  between  proper  binary  relations  and  combinatorial  graphs. 
This  strongly  suggests  a  visualization  technique  for  logical  databases  that 
may  allow  the  casual  user  to  bypass  much  of  the  notation  and  abstract 
syntax. 

Finally,  we  will  explore  schedules  for  constraints  as  binary  relations.  This 
includes  further  methods  for  reordering  subgoals,  merging  recursions,  and 
propagating  constraints.  There  is  also  a  close  relationship  between  declar¬ 
ative  languages  and  parallelism.  The  mathematical  properties  of  program 
operations  such  as  associativity  and  commutativity  indicate  that  order  of 
some  computations  can  be  ignored. 
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Conclusions 


We  selected  an  existing  distributed  fact  base  and  reformulated  the  static 
portion  as  a  logical  database  of  binary  relations.  A  parser  of  C  structures 
was  built  and  a  translator  constructed  to  separate  the  information  into  re¬ 
lations  for  querying  and  updating.  We  identified  the  operations  required  to 
develop  our  queries.  Finally,  some  high  level,  decision  critical  queries  were 
formulated  to  test  flexibility.  Simple  query  transformations  were  applied  to 
improve  efficiency. 

At  the  end  of  this  first  phase,  we  find  that  the  logical  database  has  a 
relatively  simple  structure.  Once  its  structure  was  established,  a  number 
of  queries  were  immediately  available  through  unification.  These  were  sat¬ 
isfied  almost  instantaneously.  More  complex  queries  were  built  using  rules 
as  statements  of  a  recursive  programming  language,  with  power,  flexibility 
and  limited  reversibility.  The  approach  to  date  puts  us  in  a  position  to 
begin  examining  the  effort  required  to  develop  queries  and  the  computation 
time  required  to  perform  those  queries  on  the  data  one  might  expect  in  a 
battlefield  environment. 

A  single  inference  is  comparable  to  one  statement  executed  in  a  proce¬ 
dural  language.  The  number  of  inferences  involved  is  critical  to  efficiency 
and  may  be  very  large  if  the  order  of  subgoal  selections  is  not  carefully  con¬ 
trolled.  Prolog  queries  are  not  always  reversible,  partly  because  subgoals  are 
chosen  in  a  predetermined  order.  This  makes  naive  queries  more  difficult  to 
formulate  and  implies  that  careful  attention  must  be  paid  to  the  solution 
procedure  when  scheduling  subgoals.  A  view  of  programs  as  proper  binary 
relations,  along  with  an  associated  set  of  equations  between  relations,  is  a 
step  toward  understanding  and  harnessing  the  limited  reversibility  of  logic 
programs. 

The  primary  claim  of  this  work  is  that  logical  databases  are  a  conve¬ 
nient  vehicle  for  the  management  of  battlefield  information.  The  primary 
advantages  are  improved  program  maintenance,  reliability,  efficiency  and 
generality.  While  no  system  can  perfectly  represent  a  distributed  database, 
we  have  begun  applying  a  logical  model  that  is  an  attractive  compromise, 
viewing  both  queries  and  data  as  proper  binary  relations.  The  query  lan¬ 
guage  we  will  use  has  a  set  of  operations  with  an  associated  theory.  This 
theory  is  independent  of  the  data  and  should  be  unaffected  by  its  volatility. 
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